In my first story ‘User Experience is …’ I promised that …
"over the course of a few stories, I’ll try and cover a few of the sciences we draw upon in our art as a creative community to create engaging experiences."
We’re all product people, we work in and around products in order to deliver the best experience or service possible. I’ve worked for a long time with Product Managers to share and articulate what problem we are trying to solve and what value we’re adding.
This often results in the need for a roadmap. But this is where things can go wrong. A roadmap isn’t an A-Z plan but instead an idea around the direction your heading. For you to use to communicate the approach and how you plan to sense and respond to changes that come up, feedback on what’s delivered and how you’re currently delivering value.
So choosing the right planning horizon to design to and share is key. As product manager and product owners, we need to forecast the likely development of our products. This creates a shared understanding of the benefits and features a product will provide thereby aligning the development team and stakeholders. But which timeframes and planning horizons should we take into account? And how far into the future should we look?
Too far out and you’re a dreamer and not realistic with what can be delivered. You might be designing the future, but the future may never happen.
Too close and you’re not visionary, ambitious enough or have enough foresight to see where the product could be.
In truth, pragmatism goes a long way and you have to reassure most people of the direction and also what they are going to get in the next few sprints. So designing for the now, whilst also having an eye on the future is key to this. As is the time to be able to design across the 3-time horizons ‘now’, ‘next’ and ‘future’ and also know which one to share, when and with who.
Senior stakeholders may be looking for more of the ‘future’ time horizon to make sure that everything is heading in the same direction and is aligned with other strategies. But they might also have deadlines to met, so might also want to dial back into the ‘now’ time horizon.
The engineering team might be more focussed on the ‘now’ but will want to be reassured by the ‘future’ to make sure what they are building are fit for the future and won’t need to be rebuilt.
Horizon from Pirates of the Caribbean, The Curse of the Black Pearl
“Bring me that horizon”
says Jack Sparrow at the end of the movie Pirates of The Caribbean, The Curse of the Black Pearl while steering his pirate ship into the open waters.
While Jack may seek freedom rather than the line that separates earth from sky, he could easily determine how far it is. As there is only one physical horizon on our planet, and the distance can be calculated using a standard formula.
But in product management, there are several horizons that need to be considered; how many depends on the product planning model you use. Therefore, before determining timeframes, make sure that you have a suitable model in place.
In this product planning model:
Say I want to create an app that helps people become more aware of what, when, and how much they eat:
With the right planning model in place, you can take the next step and consider appropriate time horizons to design for. It would be easy to just take the approach that each of the defined horizons would have a different timeframe, which could look something like this:
With the timeframes becoming increasingly shorter when things are more imminent and understood. The other way to look at this is the further we look into the future, the less we can see.
However the more pragmatic way to look at this would be in 3 different timeframes:
With these time horizons you can combining the vision, product objectives, and ‘time horizons’ to articulate your product strategy. This moves away from the traditional timeline roadmap and embraces the lean product roadmap.
In my experience the ‘Near Term’ time horizon should be around 12 months (assuming the product strategy covers at least the next twelve months). This allows the ‘Near Term’ to tie in with financial periods, so that value can be reviewed alongside financial stage gates. So it’s useful to review product goals and value on the roadmap quarterly like acquiring new users, increasing engagement, generating revenue, and removing technical debt. Shared goals create focus and alignment, and they make it easier to understand if the product is providing the desired benefits.
Using this approach allows a more concise and focussed backlog in the ‘Current’ time horizon, concentrating on the next roadmap goal, instead of containing outstanding work for years to come, which can be unwieldy and unworkable.
While planning ahead is important, it’s not enough. Things are likely to change and you can’t plan for every eventuality. The further ahead you look the more uncertain and unknown things become so regularly reviewing and asking for feedback on your time horizons and plans is critical.
‘Near Term’ and ‘Future’ horizons should be reviewed and adapted every 3 months, in line with reviewing investments and value of the product.
The ‘Current’ horizon should be inspected and adapted whenever new feedback or data is available to inform the backlog.
If you’re interested in finding more about product roadmaps have a look at:
User Experience is … defining a good product roadmap
Why most roadmaps should be roadmaps and not just gant charts of features
User Experience is … lean roadmapping
How do you know where your product is going, feed in user problems and feedback and measure the impact of your product
Next up I’m going to get right back to it and dive really deep into User Experience and interaction to look at which is best, hand-holding or being forgiving?
Originally written as part of the ‘User Experience is …’ series for UX Collective.